Skip to content

Added a flag which allows disabling locks with Hive catalog#3121

Open
jcellary wants to merge 6 commits intoapache:mainfrom
Automattic:main
Open

Added a flag which allows disabling locks with Hive catalog#3121
jcellary wants to merge 6 commits intoapache:mainfrom
Automattic:main

Conversation

@jcellary
Copy link

@jcellary jcellary commented Mar 4, 2026

This PR introduces a new flag LOCK_ENABLED in hive catalog. It is set to true by default to allow for backwards compatibility. If set to false no locks are being created when writing/committing a table.

Rationale for this change

In our production environment we are relying on our own external locking mechanism, so locks are not needed here and furthermore they are causing deadlocks. The current implementation creates a lock, writes data and then removes the lock. When the application dies during data write in a hard way (without a chance to run the finally clause of try catch) then the lock is never removed. There is no mechanism in the lib of removing stale old locks and checking their age. So the effect of that is that when one of the job dies in the wrong moment, all other jobs are stuck forever. Currently in our prod environment every few weeks we have to remove the contents of HIVE_LOCKS table to unblock jobs.

To prevent this from happening we introduced a flag which allows skipping creation of locks.

Are these changes tested?

Yes, we are running a fork with these changes on our production cluster

Are there any user-facing changes?

No

Copy link
Member

@geruh geruh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for raising @jcellary, I was taking a look at the locking behaviour on the java side and it looks like they are tracking at the table property level what do you think about moving that direction so we have parity in pyiceberg?

https://github.com/apache/iceberg/blob/main/hive-metastore/src/main/java/org/apache/iceberg/hive/HiveTableOperations.java#L266

@jcellary
Copy link
Author

jcellary commented Mar 6, 2026

what do you think about moving that direction so we have parity in pyiceberg

great idea, definitely makes sense to be consistent between clients. I'll refactor my PR.


return _do_wait_for_lock()

def _do_commit(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: can you move this below the commit_table function so that github diff can (hopefully) render it better

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants